Mobile application management (MAM) relates to software and services for provisioning and controlling access to internally developed and commercially available mobile apps used in business settings on both company-provided and “bring your own” smartphones and tablet computers.
Enterprise mobile application management is increasingly important due to the widespread adoption and use of mobile applications in business settings. The “bring your own device” (BYOD) phenomenon makes mobile application management more important, with personal PC, smartphone and tablet use in business settings (vs. business-owned devices) significantly increasing. Mobile application management enables corporate IT staff to download required applications, control access to business data, and remove locally-cached business data from the device if it is lost, or when its owner no longer works with the company. A growing demand for mobile apps from employees is prompting organizations to broaden beyond mobile device management to managing a growing number of mobile applications.
An end-to-end MAM solution can provide the ability to control the provisioning, updating and removal of mobile applications via an enterprise app store, monitor application performance and usage, and remotely wipe data from managed applications.
Mobile device management (MDM) is an industry term for the administration of mobile devices, such as smartphones, tablets, laptops and desktop computers. MDM is usually implemented with the use of a third party product that has management features for particular vendors of mobile devices. For example, Good Technology provides MDM software.
MDM functionality can include over-the-air distribution of applications, data and configuration settings for all types of mobile devices, including mobile phones, smartphones, tablet computers, mobile printers, mobile POS devices, etc. Most recently laptops and desktops have been added to the list of systems supported. MDM tools are used for both company-owned and employee-owned (BYOD) devices across the enterprise or mobile devices owned by consumers. Consumer demand for BYOD is now requiring a greater effort for MDM and increased security for both the devices and the enterprise to which they connect. By controlling and protecting the data and configuration settings for all mobile devices in a network, MDM can reduce support costs and business risks.
With mobile devices becoming commonplace and increased numbers of applications becoming available for mobile devices, mobile monitoring is growing in importance. Numerous vendors help mobile device manufacturers, content portals and developers test and monitor the delivery of their mobile applications. This testing is done in real-time by simulating the action of thousands of customers and detecting and correcting bugs in the applications.
Typical solutions include a server component, which sends out the management commands to the mobile devices, and a client component, which runs on the mobile device and implements the management commands.
Central remote management uses commands sent over the air to mobile device handsets. An administrator at a mobile operator, an enterprise IT data center or a handset OEM can use an administrative console to update or configure any one handset, group or groups of handsets. The Open Mobile Alliance (OMA) has specified a platform-independent device management protocol called OMA Device Management. It is supported by several mobile devices, such as PDAs and mobile phones.
Over-the-air programming (OTA) capabilities are a component of mobile network operator and enterprise-grade mobile device management software. These include the ability to remotely configure a single mobile device, an entire fleet of mobile devices or any IT-defined set of mobile devices; send software and OS updates; remotely lock and wipe a device; and do remote troubleshooting. OTA commands are sent as binary messages, which are messages including binary data.
Mobile device management software enables corporate IT departments to manage the many mobile devices used across the enterprise; consequently, over-the-air capabilities are in high demand. Enterprises using OTA as part of their MDM infrastructure demand high quality in the sending of OTA messages. Present day MDM solutions offer both Software as a Service (SaaS) and on-premises models.
As mentioned above, one example of mobile device management software is provided by Good Technology which provides some degree of control and visibility for an administrator of mobile devices. IT managers ensure that mobile devices comply with their organization-specific IT policies and that the correct configuration is pushed to devices. Good's mobile device management software permits users to self-enroll over-the-air. In addition to automatically configuring corporate policies and controls, IT can automatically setup WiFi, VPN and Exchange ActiveSync configurations on mobile devices.
An administrator (admin) defines and deploys policies for an organization. The admin may choose from a set of policy controls over password, device encryption, camera, Wi-Fi, VPN, etc. If a device is lost, stolen, retired or replaced, the admin can wipe data from the device to reduce the chance of data loss.
The admin can control and manage various devices from a single console. Good's MDM supports a wide array of mobile devices, operating systems and technologies including Apple iOS, Apple Watch, Android, Windows Pro, Window Phone and Samsung KNOX. Whether Bring Your Own Device (BYOD), Corporate-Owned, Personally-Enabled (COPE) devices or a combination of both are utilized, customizable policies ensure the right policies are applied to the right device.
Good's MDM supports use cases including business users, remote workers, highly-sensitive users, shared devices, and kiosks. Good's MDM can be deployed using a fully cloud-based deployment. Good's MDM can be fully integrated with Good Technology's Dynamics Secure Mobility Platform.
As users of mobile devices desire to and are able to install applications from numerous various sources that are beyond the control of an administrator, there is an increased risk that malware or other undesirable software may be installed. One source of software available to users, that may be beyond the control of or monitoring by administrators, is peer-to-peer file sharing (e.g., using the BitTorrent protocol). In some cases, certain file sharing sources may be untrusted or even a known bad source of software loaded onto mobile devices.
BitTorrent is a protocol for peer-to-peer file sharing used to distribute large amounts of data over the Internet. BitTorrent is one of the most common protocols for transferring large files. To send or receive files, a user must have a BitTorrent client (a computer program that implements the BitTorrent protocol).
Some popular BitTorrent clients include Xunlei, Transmission, μTorrent, MediaGet, Vuze and BitComet. BitTorrent trackers provide a list of files available for transfer, and assist in transferring and reconstructing the files. BitTorrent clients are available for a variety of computing platforms and operating systems including an official client released by BitTorrent, Inc. As of January 2012, BitTorrent is utilized by 150 million active users according to BitTorrent, Inc.
The BitTorrent protocol provides no way to index torrent files. As a result, a comparatively small number of websites have hosted a large majority of torrents, many linking to copyrighted material without the authorization of copyright holders. There is controversy over the use of BitTorrent. BitTorrent metafiles themselves do not store file contents. Whether the publishers of BitTorrent metafiles violate copyrights by linking to copyrighted material without the authorization of copyright holders is controversial.
Several studies of BitTorrent indicate that a large portion of files available for download via BitTorrent contain malware. In particular, one small sample indicated that 18% of all executable programs available for download contained malware. Another study claims that as much as 14.5% of BitTorrent downloads contain zero-day malware.
In contrast to potentially untrusted or risky sources such as BitTorrent above, in other cases, applications may be installed on mobile devices by users from known good sources. For example, a common source of applications installed on mobile devices using the Android system is the Google Play store.
The Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate does not need to be signed by a certificate authority. Rather, it is typical for Android applications to use self-signed certificates.
Android applications that are not signed will not be installed on an emulator or a device. When a developer is ready to release an application for end-users, the developer signs it with a suitable private key. The developer can use self-signed certificates to sign the developer's applications. No certificate authority is needed.
The Android system tests a signer certificate's expiration date only at install time. If an application's signer certificate expires after the application is installed, the application will continue to function normally. The developer can use standard tools (e.g., Keytool and Jarsigner) to generate keys and sign the developer's application .apk files.
The Android system will not install or run an application that is not signed appropriately. This applies wherever the Android system is run, whether on an actual device or on the emulator.
When a developer builds in release mode, the developer uses its own private key to sign the application. When the developer compiles the application in release mode, a build tools uses the developer's private key along with a Jarsigner utility to sign the application's .apk file. Because the certificate and private key used are owned by the developer, the developer provides the password for the keystore and key alias. Some aspects of application signing may affect how the developer approaches the development of its application, especially if the developer is planning to release multiple applications.
In general, the recommended strategy for all developers is to sign all of the developer's applications with the same certificate, throughout the expected lifespan of these applications. As the developer releases updates to its application, the developer must continue to sign the updates with the same certificate or set of certificates, if the developer wants users to be able to upgrade seamlessly to the new version. When the system is installing an update to an application, it compares the certificate(s) in the new version with those in the existing version. If the certificates match exactly, including both the certificate data and order, then the system allows the update. If the developer signs the new version without using matching certificates, the developer must also assign a different package name to the application—in this case, the user installs the new version as a completely new application.
When the developer has an application package that is ready to be signed, the developer can sign it using the Jarsigner tool. To sign the application, the developer runs Jarsigner, referencing both the application's APK and the keystore containing the private key with which to sign the APK.
Maintaining the security of a private key is of critical importance, both to the developer and to the user. If the developer allows someone to use the developer's key, or if the developer leaves its keystore and passwords in an unsecured location such that a third-party could find and use them, the developer's authoring identity and the trust of the user are compromised.
If a third party should manage to take a developer's key without the developer's knowledge or permission, that person could sign and distribute applications that maliciously replace the developer's authentic applications or corrupt them. Such a person could also sign and distribute applications under the developer's identity that attack other applications or the system itself, or corrupt or steal user data. A developer's reputation depends on the developer securing its private key properly, at all times, until the key is expired.